fix: consume plans on implementation#1133
fix: consume plans on implementation#1133UtkarshUsername wants to merge 2 commits intopingdotgg:mainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
size:XL
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a9026795ba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
UtkarshUsername
changed the title
Plan is still visible in the sidebar by the way, in case you were wondering |
|
UtkarshUsername#2 is stacked on top of this. After this PR is merged, will retarget that to main (see https://pr-navigator.pages.dev/t3code-utkarsh). |
1 participant
You can see my PRs and issues at https://pr-navigator.pages.dev/t3code-utkarsh.
Fixes #770
What Changed
This changes the primary same-thread
Implementflow so a proposed plan is consumed when its implementation turn actually starts.The PR includes the shared plan-consumption plumbing needed to support that behavior end to end:
thread.turn.startcan reference a source proposed planOn the web side, the same-thread
Implementaction now passessourceProposedPlan. As a result, once the implementation turn starts successfully, the thread no longer treats that plan as actionable and the plan follow-up UI disappears.This branch intentionally does not change
Implement in new thread. That will follow in a stacked PR reusing the same plumbing.Why
Before this change, same-thread implementation switched the thread out of
planmode, which hidPlan Readytemporarily, but it never consumed the underlying proposed plan in domain state.That meant the plan could become actionable again later if the thread returned to
planmode or another client reloaded from the read model. This also prevented users from making multiple plans in the same thread (see #770). The fix is to make plan consumption explicit and tie it to the accepted start of the implementation turn, not to a UI mode switch.UI Changes
Before:
(Plan has already been implemented but it still shows the implementation/refine UI.)
After:
(Same-thread
Implementconsumes the plan once the implementation turn actually starts. The thread no longer shows the follow-up plan actions for that consumed plan.)Checklist
Note
Mark proposed plans as implemented when a follow-up turn starts on an implementation thread
thread.turn.startcommand includes asourceProposedPlanreference, the decider validates the source plan exists on the same project and embeds it in thethread.turn-start-requestedevent.turn.startedevent that matches the provider's expected active turn,ProviderRuntimeIngestiondispatches athread.proposed-plan.upsertwithimplementedAtandimplementationThreadIdset on the source plan.implemented_at/implementation_thread_idtoprojection_thread_proposed_plansandsource_proposed_plan_thread_id/source_proposed_plan_idtoprojection_turns.sourceProposedPlanwhen sending a follow-up turn start and uses the newhasActionableProposedPlanhelper to hide the follow-up prompt and 'Plan Ready' status for already-implemented plans.Macroscope summarized b676658.